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(54) Voice over Internet protocol network architecture 



(57) Voice and media services are provided over an 
IP network incorporating a plurality of nodes and in 
which connection oriented traffic is transported in tun- 
nels via said nodes. SS7 signalling is provided between 



nodes. The voice and media components are multi- 
plexed to form a point to point protocol (PPP) session 
which is switched end to end across the network under 
the control of the signalling. 
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Description 

[0001] This invention relates to systems and methods 
for providing and managing Internet protocol (IP) con- 
nection oriented services. s 

BACKGROUND OF THE INVENTION 

[0002] The Internet Protocol was initially defined for 
connectionless services. These services normally oper- 
ate on a best effort basis. There is now a keen interest 
in the provision of voice services over the Internet where 
costs are significantly less than those associated with 
the conventional PSTN. However, the adaptation of 
what is effectively a high priority connection oriented 
service to a 'best effort' connectionless or packet system 
has introduced a number of significant problems. In par- 
ticular, if an Internet voice service is to obtain universal 
acceptance, it must provide a quality of service similar 
to that currently provided by conventional voice net- 
works. 

[0003] A number of workers are currently addressing 
this problem. For example, the current Internet Ipv4 pro- 
tocol includes a TOS (type of service) octet, and Ipv6 a 
traffic class octet which allows a number of priority levels 
to be defined to support some degree of traffic engineer- 
ing in an IP network. The IETF Differentiated Services 
Working Group has recently defined a method whereby 
traffic is classified at a priority level and is policed on 
entry to an IP network. Traffic behaviour on internal links 
(per hop behaviour) is specified. It is expected that using 
these methods then service level agreements can be 
offered to users provided that the number of internal 
hops is low and also provided that the percentage of 
high priority traffic is a small percentage of the total traf- 
fic. 

[0004] Other IETF Working Groups have defined pro- 
tocols providing some degree of connection orientation. 
These are> 

Multi Protocol Label Switching (MPLS) includes the 
ability to tunnel through many routing stages and to 
do so using explicit routing rather than hop-by-hop 
routing. This is a form of connection orientation. 

Layer 2 Tunnelling Protocol (LTP) provides a sig- 
nalling system to dynamically create and delete IP 
point to point protocol (PPP) sessions end to end 
across a tunnel. These sessions are allocated 
bandwidth, are timed for billing purposes, and are 
explicitly deleted on completion. This is a fully con- 
nection oriented paradigm. 

[0005] Connection orientation is of particular value in 
the provision of carrier network services to individual us- 55 
ers or to user networks. In particular it simplifies the 
tasks of:- 



Guaranteeing bandwidth. 
Ensuring Quality of service. 
Authenticating end user identities. 
Preventing fraudulent access or misuse of resourc- 
es. 

[0006] Existing Layer 2 networks such as Frame Re- 
lay or ATM are able to provide an effective control frame- 
work to provide bandwidth accounting however their 
control protocols are not sufficiently integrated into the 
Layer 3 IP network functionality to ensure that QoS char- 
acteristics of user services are maintained. This has lim- 
ited the exploitation of this characteristic and has thus 
failed to resolve the provision of QoS in the Internet. 
[0007] Reference is here directed to our co-pending 
application of even date (reference ID1068), the con- 
tents of which are incorporated herein by reference, 
which relates to a network architecture in which a net- 
work of layer 2 protocol (L2TP) tunnel switches provides 
an end of end connection oriented operation for PPP 
sessions. 

SUMMARY OF THE INVENTION 

[0008] An object of the invention is to minimise or to 
overcome the above disadvantage. 
[0009] In addition it is recognised that ITU Signalling 
System No 7 (SS7) is of considerable value in Voice 
over IP networks as it allows access to Intelligent Net- 
work applications of the PSTN/ISDN and also provides 
service transparency whereby services such as Call 
Waiting can operate consistently for ISDN to ISDN, VoIP 
to ISDN and VoIP to VoIP calls. 

[0010] In a first aspect, the invention provides an ar- 
rangement for providing voice and media service com- 
ponents over an IP network incorporating a plurality of 
nodes and in which connection oriented traffic is trans- 
ported in tunnels via said nodes, the arrangement com- 
prising means for providing signalling between said 
nodes, and means for multiplexing the voice and media 
components to form a point to point protocol (PPP) ses- 
sion, and means for switching said PPP session end to 
end across the network under the control of said signal- 
ling. 

[0011] In another aspect, the invention provides a 
method of providing voice and media service compo- 
nents over an IP network incorporating a plurality of 
nodes, the method comprising providing signalling be- 
tween said nodes, and multiplexing the voice and media 
components to form a point to point protocol (PPP) ses- 
sion which session is switched end to end across the 
network under the control of said signalling. 
[0012] Preferably, the signalling comprises SS7 sig- 
nalling. 

[0013] Typically, the network tunnels comprise Layer 
2 Tunnelling Protocol (L2TP) tunnels and Multi Protocol 
Label Switching (MPLS) tunnels. 
[0014] In a preferred embodiment, gatekeepers are 
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provided at either end of each tunnel so as to control the 
number of calls admitted to that tunnel. This enables the 
provision of quality of service guarantees to the admitted 
traffic. 

[0015] This invention thus provides a network archi- 
tecture for Voice over IP services in which e.g. SS7 sig- 
nalling is used between Voice over IP nodes and the 
media components between the VoIP terminals are mul- 
tiplexed to form a PPP Session which is switched end 
to end across the wide area network. 

BRIEF DESCRIPRION OF THE DRAWINGS 

[0016] A preferred embodiment of the invention will 
now be described with reference to the accompanying 
drawings in which:- 

Figure 1 , illustrates the MPLS mechanisms for tun- 
nelling and explicit routing; 

Figure 2 illustrates the MPLS label processing func- 
tions performed in routing a packet through an ex- 
ample connection oriented tunnel of figure 1 ; 

Figure 3 illustrates the establishment of an IP (PPP) 
session in an L2TP tunnel; 

Figure 4 illustrates a hardware fabric employed in a 
preferred embodiment of the invention and which is 
arranged to operate as a Layer 3 MPLS Router, a 
Layer 2 MPLS Tunnel Switch and a Layer 2 IP 
(PPP) Session Switch; 

Figure 5 and the associated flow chart of figure 5a 
together illustrate the establishment of an end-to- 
end IP (PPP) Session having bandwidth guaran- 
tees and enabling the end-to-end operation of 
standard PPP authentication and encryption proto- 
cols; 

Figure 6 illustrates the IP Network Configuration of 
this invention; and 

Figure 7 shows a message sequence chart for the 
establishment of a successful call between two 
Voice over IP terminals. 

DESCRIPTION OF PREFERRED EMBODIMENT 

[0017] Reference will first be made to figures 1 to 3a 
which are introduced for comparative and explanatory 
purposes, and for the purpose of facilitating a fuller un- 
derstanding of the invention. 

[0018] Referring to figure 1, which is introduced for 
explanatory and comparative purposes, this shows a 
prior art MPLS network. The network comprises a 
number of MPLS edge routers 11 and MPLS switching 
nodes 12. Such a network allows tunnels to be defined 
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and used for explicit end to end routing of packets. Pack- 
et traffic contained within a tunnel passing through a 
switching node is effectively ignored by that node as far 
as routing is concerned. The tunnels can be defined at 
s several layers, and tunnels of one layer can be carried 
within tunnels of other layers. For the purpose of illus- 
tration, engineering tunnels 1 3a, 1 3b etc. are defined for 
an engineering layer which is used to divide up capacity 
in the physical network, and user tunnels 1 4, which uti- 
lise capacity of the engineering tunnels, are defined in 
order to provide end user services. An engineering tun- 
nel may of course accommodate a number of user tun- 
nels, and a user tunnel will, in general, pass through 
more than one engineering tunnel. As shown in figure 
1 , the user tunnel 1 4 is contained in the engineering tun- 
nels 1 3a and 1 3b. A typical end user service would be 
a guaranteed bandwidth service between two VPN user 
nodes. 

[0019] In the network of figure 1 , an engineering tun- 
nel is a permanent or semi-permanent entity that is set 
up across a number of network nodes, but which does 
not in general provide a complete end to end route 
across the network. A user tunnel is a temporary entity 
that is set up within an appropriate number of engineer- 
ing tunnels to provide end to end connectivity for the 
duration of a network transaction, and which is torn 
down when that transaction has been completed. The 
purpose of a tunnel is to facilitate routing of packets. A 
packet within a tunnel can pass through a node without 
that node needing to have any knowledge of the desti- 
nation of that packet, nor even of the next node at which 
the packet will arrive, as the packet can remain within 
the tunnel until emerging at its final destination. The only 
information required by the node is the identity of the 
tunnel via which the packet is transported. It will be un- 
derstood that an IP network incorporating the tunnel 
concept may carry both tunnelled packet traffic and con- 
ventional packet traffic that is routed at each system 
node through which it passes. 

[0020] The multt protocol label switching (MPLS) op- 
eration of the network of figure 1 is depicted in figure 2 
which illustrates the typical packet format P1 -P6 at each 
of the stages in the routing of an IP packet pay load end 
to end across the network of figure 1 . A typical MPLS 
packet comprises the original IP packet together with a 
stack of labels which are used by the MPLS nodes 12 
through which the packet passes to control the onward 
routing of the packet. At each node, the current packet 
label is used to determine the onward routing of the 
packet, i.e. the tunnel to which the packet is allocated. 
The labels are typically each of 4 bytes length compris- 
ing a 20 bit label value, a 3 bit class of service field, used 
to maintain QoS differentiation, a 1 bit "bottom of stack" 
indicator and an 8 bit "time to live" field, which is used 
to detect packet forwarding loops. 
[0021] The packet formats P1 -P6 are selected in or- 
der to achieve explicit forwarding of the packet over a 
user tunnel which is itself contained within first and sec- 
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ond engineering tunnels in order to reach the destination 
edge router. MPLS is designed such that it is possible, 
at each node, to forward the packet based on the label 
at the top of the stack. 

[0022] As shown in figure 2, the packet format P1 has 
labels L~d, L-u1 , and L-ex. The label L-d is significant to 
the destination edge router 11 b and is a label exchanged 
by the label distribution protocol over the user tunnel. L- 
u1 is the first label of a series used for the user tunnel 
and is exchanged over the first engineering tunnel 13a. 
L-ex is a label for the engineering tunnel 13a. 
[0023] The packet format P2 is used by the first node 
12 to determine that this is the penultimate node for the 
first engineering tunnel 1 3a. This leads to a "pop" of the 
stack so that the labels L-d and L-u1 are forwarded to 
the next node. It will be understood that the term "pop- 
ping" of a label stack refers to the removal of the label 
currently at the head of the stack, and that the term 
"pushing" of a label refers to the addition of a label to 
the stack. 

[0024] The label L-u1 of the packet format P3 is used 
to forward the packet and is translated to the label L-u2 
for the next hop. 

[0025] The label L-u2 of the packet format P4 is used 
for forwarding. It is determined that this is the penulti- 
mate hop from the perspective of the user tunnel so label 
L-u2 is popped. It is also determined that the second 
engineering tunnel 13b is used, L-ey being a label for 
the engineering tunnel 13b. The packet is therefore for- 
warded with the labels L-d and L-ey. 
[0026] At the penultimate node of the second engi- 
neering tunnel 1 3b, the label L-ey of the packet format 
P5 is popped so the packet arrives at the destination 
edge router 11b with the label L-d only. 
[0027] At the destination edge router 11b, the original 
IP packet (format P6) is forwarded to the final destina- 
tion on the Lan. 

[0028] A further example of tunnelling prior art, illus- 
trated for explanatory and comparative purposes in fig- 
ures 3 and 3a, is the layer 2 tunnelling Protocol (L2TP). 
L2TP is used for dial-up services where the point of net- 
work service is different from the point at which the orig- 
inal dialup call is made. An example is Internet service 
provider (ISP) roaming whereby the dialup is terminated 
at the nearest ISP but the network service is provided 
by the original or home ISP L2TP provides a connection 
signalling mechanism so that point to point protocol 
(PPP) sessions can be dynamically multiplexed within 
the tunnel. PPP payload packets have a short header 
prepended thereto so that the original PPP packets can 
be identified and forwarded as appropriate. 
[0029] Figure 3 further illustrates a new call from a us- 
er terminal 30 arriving at a L2TP access concentrator 
(LAC) 31 from a dial-up modem connection set up via a 
PSTN 32. The associated messaging is illustrated in fig- 
ure 3a. It is determined that the call is destined for a 
remote L2TP network server (LNS) 33 coupled to IP net- 
work 35. A user tunnel 34 is thus established across the 
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IP network between the concentrator 31 and the remote 
server 33. An exchange of messages within the L2TP 
tunnel 34 leads to an allocation of a call ID within the 
tunnel 34 which can be used to identify packets in both 

s directions related to this call. 

[0030] Having described the prior art network opera- 
tion in order to facilitate a fuller understanding of the in- 
vention, preferred embodiments of the invention will 
now be described by way of example with reference to 

10 figures 4 to 7 of the accompanying drawings. 

[0031 ] Referring first to figure 4, this depicts the inner 
core and the surrounding circuitry of a router or switch 
according to a preferred embodiment of the invention. 
As shown in figure 4, the switch incorporates an inner 

is core 40 comprising a set of ingress functions 45 coupled 
to respective ingress ports 47, and a set of egress func- 
tions 46 coupled to respective egress ports 48. Any in- 
gress function can route a received packet to any egress 
function. The ingress and egress ports coupled to the 

20 respective ingress and egress functions handle packet 
traffic that is routed from node to node, i.e. not contained 
within a tunnel. Tunnel based traffic is received e.g. from 
tunnel T41 which either terminates at or passes through 
the node. The tunnel T41 may be an engineering tunnel 

25 accommodating a number of user tunnels. 

[0032] The lower half of figure 4 shows a decomposi- 
tion of the ingress and egress functions of the switch. A 
Tunnel Status store provides an identification of whether 
the tunnel type is MPLS or L2TP and also the mainte- 

30 nance status of the tunnel. This is used by the L2TP/ 
label header discriminator to access the header infor- 
mation and to execute any required Push/Pop opera- 
tion. The header information is used to access the Call 
Id translation & segregation function in order to identify 

35 the required egress function and to modify the L2TP 
headers for onward transmission. The packet is then for- 
warded on a link to the required egress function. In the 
typical switch fabrics, e.g. ATM, the packet will have 
been segmented for transport purposes. I n this case the 

40 packet is reassembled in the egress function for egress 
control purposes, the header of the packet as modified 
by the ingress function providing all the control informa- 
tion required for egress. The tunnel status store discrim- 
inates between MPLS and L2TP operation. The header 

45 can be further processed by additional push/pop oper- 
ations or by Tunnel id/Call id translations. The packet is 
then passed to the scheduler for transmission. Advan- 
tageously, the scheduler includes a weighted fair queu- 
ing function in order to maintain a fair discard operation 

so in the event of overload. 

[0033] In the arrangement of figure 4, IP packets that 
are received at the switch from tunnel T41 are output 
into tunnel T42. If the IP packets are already in MPLS 
format then they are directly forwarded to the inner core 

55 41 of the switch. For IP Packets which are in their normal 
format, an additional function, not shown, is required to 
process the IP address and establish an MPLS label ac- 
cording to the forwarding equivalence class, i.e. the set 
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of IP addresses which share a common MPLS label. 
The provision of such a function will be understood by 
those skilled in the art. A switch on a single card is typ- 
ically made up from four VLSI components, each of 
which provides 622 MB/s of switching capacity. Each 
VLSI component comprises an ingress function 45 and 
an egress function 46. The ingress function 45 process- 
es the initial MPLS label. For normal MPLS packets, a 
treatment indicator determines whether to PUSH/POP 
the label stack and/or translate the label. Where the in- 
itial MPLS label indicates that an L2TP tunnel is con- 
tained within the label, then a second pass is performed 
interpreting the second header as an L2TP header with 
its own treatment indicator. The initial ingress function 
45 selects an egress port 48 for forwarding. The packet 
is segmented by the ingress port 44 and forwarded typ- 
ically as 64 byte segments to the egress port. The 
egress port reassembles the packet and has an addi- 
tional treatment indicator, which it uses to prepend the 
final headers and labels before forwarding the packet 
on to the next switching node. 

[0034] The switch architecture of figure 4 embodies a 
connection control architecture which provides a range 
of connection oriented services in Internet Protocol (IP) 
networks. This architecture, which applies recursively at 
multiple levels, can be used to establish engineering 
tunnels in the physical network and user tunnels within 
these engineering tunnels. The architecture can also be 
used to establish PPP Sessions within a succession of 
L2TP tunnels. The L2TP tunnels can be mapped onto 
MPLS tunnels, and the MPLS tunnels can hide details 
of the IP network topology from the L2TP layer network 
Referring now to figures 5 and 5a, these figures illustrate 
an exemplary embodiment in which two system nodes 
generally indicated as 10, each incorporating a respec- 
tive L2TP tunnel switch 11, are interconnected through 
an ATM network 12. Each tunnel switch 11 is associated 
with a respective session manager 13. An application 
server 14 associated with the TM network 12 operates 
on a proxy signalling basis and requests point to point 
protocol (PPP) sessions on behalf of its clients. Each 
PPP session request identifies its respective endpoints 
using layer 2 tunnelling protocol (L2TP) addressing with 
the address space covering a full E164 number. The 
system operates on a source routed basis as in the case 
of the ATM Forum PNNI signalling system. The system 
nodes 1 0 exchange topology state packets identifying 
the network topology and reporting on available band- 
width or congestion so that each node has a picture of 
the current status of the network. For example, a ses- 
sion request (A, B , DTL(N1,N2)) is a request for a PPP 
session between users A and B with a designated transit 
list (DTL) for network nodes N1 and N2. The topology 
state packets that are exchanged between the nodes 
provide sufficient information on bandwidth availability 
to ensure that the nodes N1 and N2 have a high prob- 
ability to provide a successful routing. 
[0035] In the network of figure 5, each L2TP Tunnel 



exchanges the standard sequence of messages defined 
for L2TP; i.e. Call Request, Call Reply and Call Con- 
nected. These messages may relate to outgoing calls 
or incoming calls. The session managers link the partial 
5 PPP sessions on each tunnel in order to provide an end 
to end PPP session via the tunnel. 
[0036] In figure 6 a preferred network configuration 
that exploits the capabilities of the tunnel network of fig- 
ure 5 to deliver voice over IP services is shown. A 
number of H.323 client terminals 21 operate on a LAN 
together with an H.323 gatekeeper 22, a number of 
proxy servers 23 and a tunnel switch 24. The proxy serv- 
ers 23 act as the endpoints of the tunnels so that the H. 
323 client terminals are not restricted in the applications 
that they can support in addition to the H.323 client. Ad- 
vantageously, each gatekeeper 22 incorporates a call 
server function which is able to operate SS7 signalling 
with other gatekeepers or with PSTN/ISDN switches 
(not shown) in the external network. 
[0037] The message sequence chart of figure 7 illus- 
trates the end to end operation for a successful call set 
up in the network of figure 6. H.323 clients with E164 
numbers A and B have respective proxy servers with 
E164 numbers P A and P B where A and P A are algorith- 
mically related. As shown in figure 7, user terminal A 
sends a set-up message (set-up(A.B)) for a call to user 
terminal B. This message is converted by the gatekeep- 
er associated with the user terminal into an SS7 IAM 
message (IAM(P A ,B,OPC=N1,DPC=N2,CICx) in which 
the originating point code (OPC) or destination point 
code (DPC) designate the particular combination of the 
gatekeeper and the tunnel switch. The circuit identifica- 
tion code (CIC) designates a PPP session that is to be 
created on an L2TP Tunnel between the two tunnel 
switches. On receipt of the alerting message from the 
called user terminal B in response to the set-up request, 
the terminating gatekeeper requests a PPP session. 
This proceeds as described with reference to figure 1a 
above. The PPP session identifier of the proxy server 
P A (Tunnel ID, Call ID) is passed back to the terminating 
gatekeeper. This information is also passed to the orig- 
inating gatekeeper as user to user information in the 
SS7 answer message ANM. This information allows the 
originating gatekeeper to complete the end to end con- 
nection. The L2TP signalling sequences exchange 
physical channel Ids, typically IP addresses, to enable 
packets to be exchanged between the proxy servers. 
[0038] Following the set-up of the connection, H.245 
capability messages are exchanged followed by re- 
quests to establish logical channels for communication. 
Advantageously, the H.245 messages are exchanged 
via the gatekeepers so that bandwidth accounting on the 
tunnels between the tunnel switches is possible. 
[0039] The media channels are routed end to end via 
the proxies using the IP addresses exchanged during 
set-up of the PPP sessions. 

[0040] The L2TP tunnel between the two tunnel 
switches behaves as an SS7 trunk group. The gate- 
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keepers at either end of the tunnel are able to control 
the number of calls admitted allowing the network to be 
dimensioned for a grade of service as in normal teleph- 
ony where all calls accepted have a guaranteed quality 
of service. The gatekeepers are also able to account for s 
the total media components set up on the tunnel, this 
allows the available bandwidth to be dynamically shared 
amongst users and controlled by policies which can be 
based on congestion, user priorities and etc. 
[0041] It will be understood that the above description 10 
of a preferred embodiment is given by way of example 
only and that various modifications may be made by 
those skilled in the art without departing from the spirit 
and scope of the invention. 



Claims 



end to end across the network under the control of 
said signalling. 

8. An method of providing voice and media services 
over an IP network incorporating a plurality of nodes 
and in which connection oriented traffic is transport- 
ed in tunnels via said nodes, the method comprising 
providing signalling between said nodes, multiplex- 
ing the voice and media services to form a point to 
point protocol (PPP) session, and switching said 
PPP session end to end across the network under 
the control of said signalling. 

9. A method as claimed in claim 8, wherein said tun- 
nels comprise Layer 2 Tunnelling Protocol (L2TP) 
tunnels and Multi Protocol Label Switching (MPLS) 
tunnels. 



1 . An arrangement for providing voice and media serv- 
ices over an IP network incorporating a plurality of 20 
nodes and in which connection oriented traffic is 
transported in tunnels via said nodes, the arrange- 
ment comprising means for providing signalling be- 
tween said nodes, means for multiplexing the voice 
and media components to form a point to point pro- 2s 
tocol (PPP) session, and means for switching said 
PPP session end to end across the network under 

the control of said signalling. 

2. An arrangement as claimed in claim 1 , wherein said 30 
signalling comprises SS7 signalling. 

3. An arrangement as claimed in claim 2, wherein said 
tunnels comprise Layer 2 Tunnelling Protocol 
(L2TP) tunnels and Multi Protocol Label Switching 35 
(MPLS) tunnels. 

4. An arrangement as claimed in claim 3, wherein 
gatekeepers are provided one at either end of each 
said tunnel so as to control the number of calls ad- *o 
mitted to that tunnel so as to ensure that all calls 
admitted have a guaranteed quality of service. 



10. A method as claimed in claim 3, wherein gatekeep- 
ers are provided one at either end of each said tun- 
nel, and the number of calls admitted to a said tun- 
nel is controlled so as to ensure that all calls admit- 
ted to that tunnel have a guaranteed quality of serv- 
ice. 

11. A method as claimed in claim 1 0, wherein each said 
gatekeeper is provided with a call server function. 

12. A method as claimed in claim 1 1 , wherein topology 
state packets are exchanged between said nodes 
so as to provide each said node with information on 
bandwidth availability. 

13. A network architecture for Voice over IP services in 
which SS7 signalling is used between Voice over IP 
nodes and the media components between, the 
VoIP terminals are multiplexed to form a PPP ses- 
sion which is switched end to end across the net- 
work. 



5. An arrangement as claimed in claim 4, wherein 
each said gatekeeper incorporates a call server 
function. 



6. An arrangement as claimed in claim 5, wherein said 
nodes are arranged to exchange topology state 
packets so as to provide each said node with infor- so 
mation on bandwidth availability 



7. A method of providing voice and media services 
over an IP network incorporating a plurality of 
nodes, the method comprising providing SS7 sig- ss 
nailing between said nodes, and multiplexing the 
voice and media components to form a point to point 
protocol (PPP) session which session is switched 
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